…groundColor transition

Summary:
On Android, a View whose backgroundColor starts as transparent and
later transitions to an opaque color loses its border-radius clipping
and renders as a rectangle. Reported in facebook#52415; iOS is unaffected.

Root cause: `setBorderRadius` only eagerly creates an inner
`BackgroundDrawable` for `ImageView`. For a regular `View` with a
transparent backgroundColor, the composite background drawable ends
up with no inner `BackgroundDrawable` at first. When the color later
becomes opaque, `setBackgroundColor` -> `ensureBackgroundDrawable`
constructs a fresh `BackgroundDrawable` and swaps `view.background`
with a new `CompositeBackgroundDrawable` via `withNewBackground`.
The freshly constructed drawable starts with 0x0 bounds, and on the
first draw the computed path is a zero-radius rectangle.

Fix: always eagerly create the inner `BackgroundDrawable` inside
`setBorderRadius`, not only for `ImageView`. This way subsequent
`setBackgroundColor` calls mutate the existing drawable in place,
avoiding the `view.background` replacement path where bounds/path are
not yet primed.

Changelog:
[ANDROID] [FIXED] - View with borderRadius renders as rectangle after transparent → opaque backgroundColor transition

Test Plan:
Added an RNTester example under Border > "Border radius with transparent → opaque background" that starts with a transparent 50x50 box with borderRadius: 25 and toggles to red on tap. Without this change the opaque state renders as a square on Android; with the fix it renders as a circle. iOS rendering is unchanged.

Revert the eager ensureBackgroundDrawable call inside setBorderRadius
so views with borderRadius but no backgroundColor don't carry an
always-allocated drawable. Instead, fix the root timing issue at the
actual site of the bug: when ensureBackgroundDrawable lazily
constructs a new BackgroundDrawable + new composite, carry the
existing composite's bounds over before assigning view.background.
This primes the new drawable with the view's real dimensions so its
first draw computes the border-radius path correctly, without
imposing cost on views that never hit this path.

Test Plan: same RNTester repro (UI > Border > "Border radius with
transparent -> opaque background").

…ke accumulated rawProps the default

Supersedes the earlier Props.cpp patch approach. The flag's
expectedReleaseValue was already true and the non-accumulated code
path has a latent correctness bug on view-flattening un-flatten
(shadow node's rawProps gets overwritten with the latest JS patch
only, so the CREATE mount item ships a partial prop set and newly-
created native Views lose props like borderRadius). See facebook#52415.

This removes the flag entirely and promotes the accumulated behavior
to be the only behavior:

- Props::initializeDynamicProps unconditionally merges previous
  rawProps with the incoming patch.
- FabricMountingManager::getProps: non-Props-2.0 path now always emits
  full rawProps for CREATE and diffDynamicProps() for UPDATE.
- FabricMountingManager executeMount INSERT: always emits
  UpdatePropsMountItem (dropped the shouldCreateView gate that only
  ran under the old flag-off branch).
- FabricUIManagerBinding: schedulerDidFinishTransaction is a no-op
  (transactions are pulled only in schedulerShouldRenderTransactions);
  the pendingTransactions_ queue and its mutex are deleted with it.
- ConcreteComponentDescriptor: enableExclusivePropsUpdateAndroid
  no longer pivots on the accumulated flag.
- Regenerated all feature-flag accessor files (Kotlin + C++) via
  `yarn featureflags --update` to drop the API surface.